perm filename CLEDIT.MSG[COM,LSP]6 blob
sn#859382 filedate 1988-07-05 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 ∂31-Mar-88 1358 chapman%aitg.DEC@decwrl.dec.com editorial subcommittee notes
C00018 ENDMK
C⊗;
∂31-Mar-88 1358 chapman%aitg.DEC@decwrl.dec.com editorial subcommittee notes
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 31 Mar 88 13:58:43 PST
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA15156; Thu, 31 Mar 88 13:52:57 PST
Date: Thu, 31 Mar 88 13:52:57 PST
Message-Id: <8803312152.AA15156@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: @[chapman]eddis@decwrl.dec.com, chapman%aitg.DEC@decwrl.dec.com
Subject: editorial subcommittee notes
Editorial Subcommittee Report
March, 1988
1 INTRODUCTION
The editorial subcommittee of X3J13 met on March 15, 1988,
from 2-5 PM at Lucid. Attendees were:
Skona Brittain Barry Margolin
Kathy Chapman Larry Masinter
Linda deMicheal Guy Steele
Dick Gabriel Walter van Roggen
Sonya Keene Bob Mathis
(did I leave anyone out?)
This memo summarizes the important results of the meeting,
and lists the action items from the meeting.
2 SUMMARY
In general, the attendees felt that the schedule for
completion of the standard was agressive, but doable. In
addition, there is an increased interest in completing the
standard on, or ahead of, schedule, due to the commitment the US
has made to the ISLISP group. Following are the decisions made by
the attendees.
1. The outline and contents of the chapters of the standard have
been modified. The next section of this memo details the
changes.
2. A formal specification of the base forms of CL will be done.
It will begin in July or sooner. Initially the work will be
done by Dick Gabriel and Kathy Chapman. It is hoped that Will
Clinger and Jonathan Rees will have time to assist with the
effort.
3. It was decided that the use of a large set of special fonts in
explanatory material (will be Chapter 3 in the new outline) is
distracting to the reader. Therefore, special fonts will only
be employed to a limited extent in Chapter 3, but will be used
more extensively in Chapter 4 (see Action Items section).
!
Page 2
4. It was decided that the use of a professional indexer is
probably desirable (see Action Items section).
5. The reader syntax and semantic rules, and other semantic rules
of the language CL, will be specified in natural language in
the form of a set of evaluation rules. These will appear in
Chapters 2 and 3 (see outline in the next section) (see Action
Items section).
6. It was decided that the issues surrounding language extensions
should be examined in detail (see Action Items section).
7. A new list of parts of the document to be reviewed, when they
will be ready for review, and who is to review them, is to be
constructed (see Action Items section).
3 NEW OUTLINE AND CONTENTS OF STANDARD CHAPTERS
Following is the new outline for the CL standard.
1. Chapter 1 - Introduction - Same outline as current chapter 1;
font key explanation is expanded, compliance section is
rewritten with clarity in mind, language extensions section is
modified (see Action Items).
2. Chapter 2 - Evaluation - This chapter will contain a clear
model of read, eval, phases of processing... (see Action
Items).
3. Chapter 3 - Concepts - This chapter will contain the following
information:
1. A description of the Lisp reader, and a forward reference
to the read function. In addition, the character set will
appear first, and all the syntactic characteristics
(whether they involve `special' tokens or not), will
appear in the list of operators.
2. The data types section will contain an explanation of the
way CL uses data types.
3. The basic language constructs section will be moved to
Chapter 2 (the evaluation model).
4. The rest of this chapter will contain information similar
to what is contained in Chapter 1 of the CLOS
specification, i.e., an explanation of how the language
works with forward pointers to forms that will be
explained in detail (but autonomously) in Chapter 4.
!
Page 3
4. Chapter 4 - Form, Constant, and Variable Descriptions - This
chapter now includes the information that had previously been
a part of Chapters 4, 5, and 7. Following are some details
about how this chapter will look.
1. All functions, macros, special forms, constants, and
variables that are part of CL will be listed
alphabetically. All entries with non-alpha characters
appearing in the first position of the name of the entry
will be positioned at the end of the alphabetic list, and
will be alphabetized according to the first alpha or
numeric character appearing in the name of the entry.
2. The `Inputs' and `Outputs' labels in the f/m/sf
descriptions are changed to `Arguments' and `Values',
respectively.
3. The `Base' label is removed, and the fact that a f/m/sf is
part of the base is notated under the label `Notes'.
4. A `Side Effects' label has been added.
5. A `See Also' label was suggested; however, its meaning in
a strict specification is not clear. For example, does a
See Also reference mean that the information pointed to
somehow affects the result of the evaluation of the form
being described? Please comment on the addition of a `See
Also' label.
5. Chapter 5 - Syntax - same as current Chapter 8.
6. Chapter 6 - Semantics - same as current Chapter 9.
!
Page 4
4 ACTION ITEMS
Following is a list of action items resulting from both the
subcommittee meeting, and the X3J13 committee meeting. Please let
me know if I missed any items, or have incorrectly assigned an
item to a person.
Responsible people Action Item
Kathy Chapman Get X3 to pay for professional indexer
Kathy Chapman Create a format for proposal submission
Barry Margolin Create a proposal on how language extensions are
Larry Masinter to be handled
Guy Steele Create an evaluation model strawman
Dick Gabriel
Kathy Chapman Create a review cycle proposal for editorial
committee reviews
Kathy Chapman Create a review proposal for X3J13 committee
Kathy Chapman Contact typesetter to review font usage
5 OPEN ISSUES
Following is a list of decisions that have to be made at
future meetings.
1. Will new language features (like CLOS) be imbedded in the
document or will they appear as a supplement?
2. Should we specifically try to include the ISO community in our
review cycles?
3. Other issues?
6 SUMMARY
The people that reviewed the document provided highly
valuable technical insight and corrections. In order for us to
make this document as correct as possible, it will be necessary
for this sort of review to continue to the document's completion.
!
Page 5
As the document becomes larger and larger, this sort of review
becomes more and more intimidating and time-consuming. Therefore,
I'd like to request help now working out the review cycle details,
and later changing the review cycle algorithm if it doesn't work
for you. It would be much better to speak up if you don't have
time to review your part than to leave it left unread.
The first request I have may be the most important to our
success. A review cycle plan will be coming to you within this
month. Please review it carefully, analyze the time you will have
to spend on this effort, and propose a task you can comfortably
accomplish. If I don't hear from you concerning the review cycle
plan, I will assume you do not wish to review the standard. If
you are passing the document around to other people, please make
sure they realize that their timely review is necessary to the
success of this effort. An unreviewed section could potentially
remain untouched, and perhaps will be wrong. Urge the people you
are counting on to review certain parts to only volunteer for as
much as they can handle.
∂03-May-88 0658 CL-Editorial-mailer EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 88 06:58:43 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA04677; Tue, 3 May 88 06:58:45 PDT
Date: Tue, 3 May 88 06:58:45 PDT
Message-Id: <8805031358.AA04677@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, CHAPMAN%aitg.DEC@decwrl.dec.com
Subject: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
Issue: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
Category: Administrative
Edit History: Version 1, Kathy Chapman, 4/4/88
Problem Description: The editorial committee needs a standard format
for submitting proposals
Proposal: Proposals to the editorial committee should be submitted
in the following format to cl-editorial@sail.stanford.edu.
Issue: <title of issue>
Category: <administrative/technical>
Edit History: <version # - author - date>
Problem Description: <why this issue was raised>
Proposal: <solution to the issue>
Rationale: <why this solution was chosen>
Current Practice: <how the issue is currently dealt with>
Cost to Implementors: <what the solution will cost vendors to implement>
Cost to Users: <how will this solution change a user's view>
Cost of Non-adoption: <what will happen if nothing is done about the issue>
Benefits: <what added value this solution provides>
Discussion: <discussion about this issue/solution>
Rationale: Familiar, looks very similar to the clean-up committee
proposal format.
Current Practice: No proposals have been submitted yet.
Cost to Implementors: None.
Cost to Users: None.
Cost of Non-adoption: Non-standard formats for proposals will cause confusion.
Benefits: Tracking of issues with the CL standard will be easier.
Discussion:
∂03-May-88 0909 CL-Editorial-mailer Re: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 May 88 09:09:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 03 MAY 88 09:03:07 PDT
Date: 3 May 88 09:02 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of Tue, 3 May 88 06:58:45
PDT
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@sail.stanford.edu
Message-ID: <880503-090307-5141@Xerox>
I think the editorial committee will need some less cumbersome mechanisms than
those adopted by the cleanup committee; the problem in cleanup is that there
were a lot of substantive issues that actually had costs and benefits to diverse
communities. I think given the schedule you should go for something leaner:
i.e., Cathy Chapman makes the decisions, and asks the editorial committee for
advice & review.
With cl-cleanup, there were lots of proposals and no action, and the standard
format helped focus the discussions into the technical merits. Here, I don't see
a lot of proposals at all -- maybe you do? Are there some you are having trouble
dealing with?
I have difficulty dealing with the abstract; maybe a concrete example of what
you think of as an "editorial committee proposal" might help me understand what
you're getting at.
∂03-May-88 1114 CL-Editorial-mailer editorial committee meeting
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 88 11:14:31 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA17581; Tue, 3 May 88 11:14:32 PDT
Date: Tue, 3 May 88 11:14:32 PDT
Message-Id: <8805031814.AA17581@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, CHAPMAN%aitg.DEC@decwrl.dec.com
Subject: editorial committee meeting
I have requested a conference room for 6/14 in the afternoon for our
committee meeting. Does anyone have a problem with this?
kc
∂03-May-88 1118 CL-Editorial-mailer EDITORIAL-COMITTEE-STANDARD-REVIEW
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 88 11:18:15 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA17653; Tue, 3 May 88 11:18:12 PDT
Date: Tue, 3 May 88 11:18:12 PDT
Message-Id: <8805031818.AA17653@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, CHAPMAN%aitg.DEC@decwrl.dec.com
Subject: EDITORIAL-COMITTEE-STANDARD-REVIEW
Issue: EDITORIAL-COMMITTEE-STANDARD-REVIEW
Category: Administrative
Edit History: Version 1, Kathy Chapman, 4/5/88
Version 2, Kathy Chapman, 5/1/88
Problem Description:
Part 1: Reviewers must receive the parts of the
standard they are meant to review either electronically or
by hardcopy.
Part 2: Reviewers must be able to comment on those sections
they are reviewing electronically or by hardcopy.
Part 3: Reviewers' comments must be incorporated, logged, and
responded to electronically or by hardcopy.
Part 4: Reviewers must have access to the complete standard and
to the marked-up CLtL with pointers to the standard.
Proposal:
The files containing
the standard are to be located in TEX format on
chapman@hudson.dec.com::sys$sysdevice:[chapman]*.tex.
The review and comment process, if conducted electronically,
will be handled by a mail monitor. A set of functions will be
available to each group of reviewers (X3 committee, editorial
committee, and others) which will facilitate the review process.
If electronic access is not possible, it is possible to request
a hardcopy in writing or telephonically.
A summary of the mail monitor functions applicable to the X3
committee follow: (use `cl-review' as subject)
Function Keywords Description
request hardcopy (t or nil) The latest copies of all
files (list) sections you are responsible
for will be copied to
chapman@hudson.dec.com,
or mailed to your hardcopy
address (see list below).
comment file (string) The file being reviewed.
qualifier (string) Section # or contruct name.
comment (string) The comment.
A response to the comment is
sent to the reviewer and
cl-editorial. The possible
files are listed below.
update update-frequency Amount of time (in days) be-
(integer) tween copies of the standard
to hudson.dec.com (initially
this is every 30 days).
change hardcopy-address (string) Use this function to change
file-list (list) the information in the data
base that is part of this
message. You can only change
your own information.
query all-files (t or nil) Get a list of possible files
file-list (list) to review, your file list,
update-frequency current update frequency,
comment-list current list of comments.
In addition, to aid in reviewing, the mapping from the CLtL to
the standard and visa versa will be located on hudson.dec.com
in the files cltl-standard.txt and standard-cltl.txt.
Examples:
To request a hardcopy:
From: decwrl::"rpg@sail.stanford.edu"
To: chapman@hudson.dec.com
Subject: cl-review
Text: (request :hardcopy t :files '(all))
To comment on a chapter or section:
From: decwrl::"rpg@sail.stanford.edu"
To: chapman@hudson.dec.com
Subject: cl-review
Text: (comment :chapter chap3 :qualifier "3.1.1.2" :comment
"Paragraph 2: change wording from
function to macro")
Possible files are:
all (this means all you are responsible for reviewing)
book (this means the whole standard)
chap1
chap2
chap3
ARRAYS
CHARACTERS
CONTROL-STRUCTURE
DECLARATIONS
ERRORS
EVALUATOR
FILES
HASHTABLES
IO
LISTS
MACROS
MISC
NUMBERS
PACKAGES
PREDICATES
PROGRAM-STRUCTURE
SEQUENCES
STREAMS
STRINGS
STRUCTURES
SYMBOLS
TYPES
chap5
chap6
new-additions
Rationale: In order to get the standard done in a timely manner, it
is necessary that the review process be stream-lined, but
flexible.
Current Practice: None.
Cost to Implementors: If a reviewer requests a hardcopy, it will be
sent COD.
Cost to Users: Same as Cost to Implementers.
Cost of Non-adoption: The review process could, in the best case, become
unwieldy. In the worst case, reviewers could find that reviewing
the document and submitting comments is too much trouble, and
the document would thus not get reviewed.
Benefits:
1. Reviewers can review according to when their own schedules
permit, not just when the document is available.
2. Comments can be handled and logged automatically.
Discussion: Following are the default data base and the proposed review
schedule.
The default data base follows:
Sender Data
maxiv@mu.edu "Mary Boelk
Johnson Controls, MS M67
507 East Michigan St.
Milwaukee, Wisconsin 53202"
(chap1 chap3 packages symbols)
skona%csilvax@hub.ucsb.edu
"Skona Brittain
Microcomputer System Consultants
P.O. Box 747
Santa Barbara, California 93102"
(chap1 chap3 arrays control-structure declarations)
Willc%tekchips.crl@tektronix.tek.com
"Will Clinger
Semantic Microsystems
4470 SW Hall Blvd., Suite 340
Beaverton, Oregon 97005"
(chap1 chap3 chap5 chap6)
rpg@sail.stanford.edu
"Dr. Richard Gabriel
Lucid, Inc.
707 Laurel St.
Menlo Park, California 94025"
(chap1 chap2 chap3 chap5 chap6)
ida%utokyo-relay.csnet@csnet-relay.arpa
"Masayuki Ida
Aoyama Cakuin University
Computer Science Research Group
Atsugi, Kanagawa JAPAN 243-01
(book)
Gregor.pa@xerox.com
"Gregor Kiczales
Xerox PARC
3333 Coyote Hill Rd.
Palo Alto, Calif. 94304"
(chap1 chap3 clos)
barmar@think.com
"Barry Margolin
Thinking Machines
245 First St
Cambridge, Mass. 02142"
(chap1 chap3 structures evaluator)
Masinter.pa@xerox.com
"Larry Masinter
Xerox PARC
3333 Coyote Hill Rd.
Palo Alto, Calif. 94304"
(chap1 chap3 files hashtables io)
mathis@c.isi.edu
"Bob Mathis
9712 Ceralene Dr.
Fairfax, Virginia 22032-1704"
(chap1 chap3 numbers)
ohlander@VENERA.ISI.EDU
"Ron Ohlander
USC-ISI
4676 Admiralty Way
Marina del Rey, California 90292"
(chap1 chap3 lists macros)
KMP@SCRC-Stony-Brook.arpa
"Kent M. Pitman
Symbolics, Inc.
11 Cambridge Center
Cambridge, Mass. 02142"
(chap1 chap3 misc errors types)
jar@ai.ai.mit.edu
"Jonathan Rees
MIT
39 Clarendon St.
Boston, Mass. 02116"
(chap1 chap2 chap3 chap5 chap6)
jeffr@aai2.istc.sri.com
"Jeff Rininger EK339
SRI International
333 Ravenswood Avenue
Menlo Park, California 94025"
(chap1 chap3 predicates program-structure)
Rosenking@a.isi.edu
"Jeff Rosenking
Grumman Corporate Research Center
M/S A01-26
Bethpage, NY 11714"
(chap1 chap3 sequences streams)
SKeene@SCRC-Stony-Brook.arpa
"Sonya Keene
Symbolics, Inc.
11 Cambridge Center
Cambridge, Mass. 02142"
(chap1 chap3 strings characters)
gls@THINK.com
"Dr. Guy L. Steele Jr.
Thinking Machines
245 First St
Cambridge, Mass. 02142"
(chap1 chap2 chap3)
∂03-May-88 1251 CL-Editorial-mailer EDITORIAL-COMITTEE-STANDARD-REVIEW
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 3 May 88 12:51:31 PDT
Received: from fafnir.think.com by Think.COM; Tue, 3 May 88 15:49:55 EDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by fafnir.think.com; Tue, 3 May 88 15:49:50 EDT
Date: Tue, 3 May 88 15:51 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: EDITORIAL-COMITTEE-STANDARD-REVIEW
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: <8805031818.AA17653@decwrl.dec.com>
Message-Id: <19880503195119.9.BARMAR@OCCAM.THINK.COM>
I don't understand this:
Function Keywords Description
request hardcopy (t or nil) The latest copies of all
files (list) sections you are responsible
for will be copied to
chapman@hudson.dec.com,
or mailed to your hardcopy
address (see list below).
If I request a section, why will it be copied to chapman, rather than
mailed to me?
Actually, I think that transmission of sections should be done using
file transfer if feasible. Would it be possible for the sections to be
placed on a machine connected to the Arpanet, to which we could get FTP
access? Email is a very poor mechanism for distribution of large
documents.
comment file (string) The file being reviewed.
qualifier (string) Section # or contruct name.
comment (string) The comment.
A response to the comment is
sent to the reviewer and
cl-editorial. The possible
files are listed below.
I don't like having to enclose the actual comment text in a string. I
think it would be better to have the list at the beginning of the
message text, and then take the rest of the message as the text of the
comment. If you want to allow multiple comments in a single message, we
could devise an escape sequence that indicates that another comment
descriptor follows, e.g.
(comment :file chap3 :qualifier "3.1.1.2")
Blah, blah, blah.
Comment, comment, comment.
-*-End-*-
(comment :file chap1 :qualifier "1.3")
More blah, blah, blah.
Requring the comment to be in a string is prone to errors, because we
may forget to slashify doublequotes and slashes when we include them in
the comment (and we will, I guarantee it). A sequence like the above
"-*-End-*-" is unlikely to appear in a real comment.
To comment on a chapter or section:
From: decwrl::"rpg@sail.stanford.edu"
To: chapman@hudson.dec.com
Subject: cl-review
Text: (comment :chapter chap3 :qualifier "3.1.1.2" :comment
"Paragraph 2: change wording from
function to macro")
The :chapter keyword isn't mentioned in the above description of the
"comment" operation. Should that be :file?
barmar
∂03-May-88 1302 CL-Editorial-mailer re:barmar comments
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 88 13:02:21 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA22604; Tue, 3 May 88 13:02:23 PDT
Message-Id: <8805032002.AA22604@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 May 88 16:02
To: cl-editorial@sail.stanford.edu
Subject: re:barmar comments
>Actually, I think that transmission of sections should be done using
>file transfer if feasible. Would it be possible for the sections to be
>placed on a machine connected to the Arpanet, to which we could get FTP
>access? Email is a very poor mechanism for distribution of large
>documents.
That's the idea, that's why the files are being copied to a node
that has FTP access, and then you can do the copy. Mail won't work
in this case. I'd like to do the FTP automatically, but can't promise
that right now.
No strings for comments, yes it should be :file.
kc
∂05-May-88 2216 CL-Editorial-mailer EDITORIAL-COMMITTEE-STANDARD-REVIEW
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 5 May 88 22:16:06 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA04054; Thu, 5 May 88 22:16:11 PDT
Date: Thu, 5 May 88 22:16:11 PDT
Message-Id: <8805060516.AA04054@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, CHAPMAN@decwrl.dec.com
Subject: EDITORIAL-COMMITTEE-STANDARD-REVIEW
Issue: EDITORIAL-COMMITTEE-STANDARD-REVIEW
Category: Administrative
Edit History: Version 1, Kathy Chapman, 4/5/88
Version 2, Kathy Chapman, 5/1/88
Version 3, Kathy Chapman, 5/6/88
Problem Description:
Part 1: Reviewers must receive the parts of the
standard they are meant to review either electronically or
by hardcopy.
Part 2: Reviewers must be able to comment on those sections
they are reviewing electronically or by hardcopy.
Part 3: Reviewers' comments must be incorporated, logged, and
responded to electronically or by hardcopy.
Part 4: Reviewers must have access to the complete standard and
to the marked-up CLtL with pointers to the standard.
Proposal:
The files containing
the standard are to be located in TEX format on
chapman@hudson.dec.com::sys$sysdevice:[chapman]*.tex.
This machine has FTP access so that you can copy the
files you need to your location.
The review and comment process, if conducted electronically,
will be handled by a mail monitor. A set of functions will be
available to each group of reviewers (X3 committee, editorial
committee, and others) which will facilitate the review process.
If electronic access is not possible, it is possible to request
a hardcopy in writing or telephonically.
A summary of the mail monitor functions applicable to the X3
committee follow: (use `cl-review' as subject)
Function Keywords Description
request hardcopy (t or nil) The latest copies of all
files (list) sections you are responsible
for will be copied to
chapman@hudson.dec.com,
or mailed to your hardcopy
address (see list below).
comment file (string) The file being reviewed.
qualifier (string) Section # or contruct name.
A response to the comment is
sent to the reviewer and
cl-editorial. The possible
files are listed below.
update update-frequency Amount of time (in days) be-
(integer) tween copies of the standard
to hudson.dec.com (initially
this is every 30 days).
change hardcopy-address (string) Use this function to change
file-list (list) the information in the data
base that is part of this
message. You can only change
your own information.
query all-files (t or nil) Get a list of possible files
file-list (list) to review, your file list,
update-frequency current update frequency,
comment-list current list of comments.
In addition, to aid in reviewing, the mapping from the CLtL to
the standard and visa versa will be located on hudson.dec.com
in the files cltl-standard.txt and standard-cltl.txt.
Examples:
To request a hardcopy:
From: decwrl::"rpg@sail.stanford.edu"
To: chapman@hudson.dec.com
Subject: cl-review
Text: (request :hardcopy t :files '(all))
To comment on a chapter or section:
From: decwrl::"rpg@sail.stanford.edu"
To: chapman@hudson.dec.com
Subject: cl-review
Text: (comment :file chap3 :qualifier "3.1.1.2")
Paragraph 2: change wording from
function to macro.
Possible files are:
all (this means all you are responsible for reviewing)
book (this means the whole standard)
chap1
chap2
chap3
ARRAYS
CHARACTERS
CONTROL-STRUCTURE
DECLARATIONS
ERRORS
EVALUATOR
FILES
HASHTABLES
IO
LISTS
MACROS
MISC
NUMBERS
PACKAGES
PREDICATES
PROGRAM-STRUCTURE
SEQUENCES
STREAMS
STRINGS
STRUCTURES
SYMBOLS
TYPES
chap5
chap6
new-additions
Rationale: In order to get the standard done in a timely manner, it
is necessary that the review process be stream-lined, but
flexible.
Current Practice: None.
Cost to Implementors: If a reviewer requests a hardcopy, it will be
sent COD.
Cost to Users: Same as Cost to Implementers.
Cost of Non-adoption: The review process could, in the best case, become
unwieldy. In the worst case, reviewers could find that reviewing
the document and submitting comments is too much trouble, and
the document would thus not get reviewed.
Benefits:
1. Reviewers can review according to when their own schedules
permit, not just when the document is available.
2. Comments can be handled and logged automatically.
Discussion: Following are the default data base and the proposed review
schedule.
The default data base follows:
Sender Data
maxiv@mu.edu "Mary Boelk
Johnson Controls, MS M67
507 East Michigan St.
Milwaukee, Wisconsin 53202"
(chap1 chap3 packages symbols)
skona%csilvax@hub.ucsb.edu
"Skona Brittain
Microcomputer System Consultants
P.O. Box 747
Santa Barbara, California 93102"
(chap1 chap3 arrays control-structure declarations)
Willc%tekchips.crl@tektronix.tek.com
"Will Clinger
Semantic Microsystems
4470 SW Hall Blvd., Suite 340
Beaverton, Oregon 97005"
(chap1 chap3 chap5 chap6)
rpg@sail.stanford.edu
"Dr. Richard Gabriel
Lucid, Inc.
707 Laurel St.
Menlo Park, California 94025"
(chap1 chap2 chap3 chap5 chap6)
ida%utokyo-relay.csnet@csnet-relay.arpa
"Masayuki Ida
Aoyama Cakuin University
Computer Science Research Group
Atsugi, Kanagawa JAPAN 243-01
(book)
Gregor.pa@xerox.com
"Gregor Kiczales
Xerox PARC
3333 Coyote Hill Rd.
Palo Alto, Calif. 94304"
(chap1 chap3 clos)
barmar@think.com
"Barry Margolin
Thinking Machines
245 First St
Cambridge, Mass. 02142"
(chap1 chap3 structures evaluator)
Masinter.pa@xerox.com
"Larry Masinter
Xerox PARC
3333 Coyote Hill Rd.
Palo Alto, Calif. 94304"
(chap1 chap3 files hashtables io)
mathis@c.isi.edu
"Bob Mathis
9712 Ceralene Dr.
Fairfax, Virginia 22032-1704"
(chap1 chap3 numbers)
ander@VENERA.ISI.EDU "e"
"Ron Ohlander
USC-ISI
4676 Admiralty Way
Marina del Rey, California 90292"
(chap1 chap3 lists macros)
KMP@SCRC-Stony-Brook.arpa
"Kent M. Pitman
Symbolics, Inc.
11 Cambridge Center
Cambridge, Mass. 02142"
(chap1 chap3 misc errors types)
jar@ai.ai.mit.edu
"Jonathan Rees
MIT
39 Clarendon St.
Boston, Mass. 02116"
(chap1 chap2 chap3 chap5 chap6)
jeffr@aai2.istc.sri.com
"Jeff Rininger EK339
SRI International
333 Ravenswood Avenue
Menlo Park, California 94025"
(chap1 chap3 predicates program-structure)
Rosenking@a.isi.edu
"Jeff Rosenking
Grumman Corporate Research Center
M/S A01-26
Bethpage, NY 11714"
(chap1 chap3 sequences streams)
SKeene@SCRC-Stony-Brook.arpa
"Sonya Keene
Symbolics, Inc.
11 Cambridge Center
Cambridge, Mass. 02142"
(chap1 chap3 strings characters)
gls@THINK.com
"Dr. Guy L. Steele Jr.
Thinking Machines
245 First St
Cambridge, Mass. 02142"
(chap1 chap2 chap3)
∂06-May-88 0934 CL-Editorial-mailer EDITORIAL-COMMITTEE-STANDARD-REVIEW
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 May 88 09:34:02 PDT
Received: from fafnir.think.com by Think.COM; Fri, 6 May 88 12:31:38 EDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by fafnir.think.com; Fri, 6 May 88 12:31:34 EDT
Date: Fri, 6 May 88 12:33 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: EDITORIAL-COMMITTEE-STANDARD-REVIEW
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, CHAPMAN@decwrl.dec.com
In-Reply-To: <8805060516.AA04054@decwrl.dec.com>
Message-Id: <19880506163301.0.BARMAR@OCCAM.THINK.COM>
This database entry doesn't look right:
ander@VENERA.ISI.EDU "e"
"Ron Ohlander
USC-ISI
4676 Admiralty Way
Marina del Rey, California 90292"
(chap1 chap3 lists macros)
What's the "e" for? All the other entries have a single character
string between the email address and the section list.
barmar
∂26-May-88 0728 CL-Editorial-mailer EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 May 88 07:28:20 PDT
Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 410625; Thu 26-May-88 10:27:30 EDT
Date: Thu, 26 May 88 10:27 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@SAIL.STANFORD.EDU
In-Reply-To: <8805031358.AA04677@decwrl.dec.com>
Message-ID: <19880526142701.2.SKEENE@JUNCO.SCRC.Symbolics.COM>
I have the same questions Larry raised about the need for a proposal
format. What kind of proposals do you expect? I think the two kinds
of communications you're going to have with the X3J13 members are:
1. suggestions, general comments, ideas, questions, flames
2. reviews of the draft
The first category can be dealt with informally, which would probably
save administrative time on your part. We used the CLOS mailing list
this way and it worked fine. If we had kept track of those
communications we would never have finished the spec. You could save
the communications (without doing any administrative work) by
archiving the editorial mailing list.
∂26-May-88 0807 CL-Editorial-mailer EDITORIAL-COMMITTEE-STANDARD-REVIEW
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 May 88 08:07:11 PDT
Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 410651; Thu 26-May-88 11:07:19 EDT
Date: Thu, 26 May 88 11:06 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: EDITORIAL-COMMITTEE-STANDARD-REVIEW
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@SAIL.STANFORD.EDU, CHAPMAN@decwrl.dec.com
In-Reply-To: <8805060516.AA04054@decwrl.dec.com>
Message-ID: <19880526150653.3.SKEENE@JUNCO.SCRC.Symbolics.COM>
Personally, when I review documentation, I always do it in hardcopy. As
a technical writer, I haven't ever found a reviewer who prefers to do it
online. I don't know if my experience is representative. It is
probably worth asking the group if they see themselves using the
electronic mail tools you proposed.
When I get copies for Symbolians to review, I'll ftp the files to a
local machine and then print them. I don't completely understand the
process for doing that. Do I really have to use a mail monitor program
to copy files? Also, I would want to copy dvi files, not tex files.
How would I do that?
Is there anything ready for review now?
∂26-May-88 1007 CL-Editorial-mailer hard copy
Received: from hub.ucsb.edu by SAIL.Stanford.EDU with TCP; 26 May 88 10:06:35 PDT
Received: from csilvax.ucsb.edu by hub.ucsb.edu (5.59) id AA28368; Thu, 26 May 88 10:07:01 PDT
Received: from by csilvax.ucsb.CSNET (5.51) id AA16346; Thu, 26 May 88 10:00:33 PDT
Date: Thu, 26 May 88 10:00:33 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Thu, 26 May 88 10:00:33 PDT
To: cl-editorial@SAIL.Stanford.edu
Subject: hard copy
I strongly agree with Sonya about reviewing hard copy. All my experience,
as a reviewer and a reviewee, says that hard copy is preferable. At this
point I think that we should postpone discussing ways to do the work until
we start doing it and then see what tools we need to develop, if any. Since
this committee is not overwhelming in size, I don't think that that will
cause problems. Coordinating differences can probably be done by one person.
Mailing hard copy will cost money but I am quite confident that it will save
a lot of time.
I also strongly feel that hard copy should be available free to members of
the editorial committee. I do not understand why this is the only committee
that exacts a monetary price for membership - aren't time, effort, ideas, etc.
enough? At the March meeting two people told me that they agreed with my
position although they hadn't wanted to say so in front of the whole group.
So I suggest that we at least decide among ourselves how we feel about this
policy before the June meeting. I joined this committee because I felt that
it was the one to which I could contribute the most, but if I have to pay to
do so, I will withdraw from it. (as far as I know, ftp'ing files is not free
unless it's a local call, and then they still need to be printed anyway.)
skona
∂26-May-88 1123 CL-Editorial-mailer $$'s for Words
To: cl-editorial@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I am one of the people who suggested that a nomimal fee be paid by folks
who request hardcopy, and the primary targets of this charge are members
of X3J13 who are not in the subcommittee. If the basic part of the Common
Lisp specification will be about 300 pages long, and CLOS, Loop, and error
signaling are part of it, it will cost $4000 to copy and mail it to the
membership. Every CLOS mailing has cost us about $2000 to send out. The
reason is to encourage only those who will actually do the work of
reviewing the material. Another alternative is to raise the membership
fee for X3J13 to cover this cost, so that everyone will pay to get the
hard copies even if they don't want them. It seemed to me better to dun
only those who wanted it rather than everyone.
It's sort of like if you went to a big dinner and you ordered a cheap
meal, but some others ordered expensive ones, and they split the bill
evenly.
-rpg-
∂26-May-88 1134 CL-Editorial-mailer re: Sonya's comments
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 26 May 88 11:32:24 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA29787; Thu, 26 May 88 11:32:36 PDT
Date: Thu, 26 May 88 11:32:36 PDT
Message-Id: <8805261832.AA29787@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu
Subject: re: Sonya's comments
>From: DECWRL::"skeene@STONY-BROOK.SCRC.Symbolics.COM" "Sonya E. Keene 26-May-88 1106 EDT" 26-MAY-1988 11:03
>To: aitg::chapman
>Subj: EDITORIAL-COMMITTEE-STANDARD-REVIEW
>
>Cc: cl-editorial@SAIL.STANFORD.EDU, decwrl::CHAPMAN
>Personally, when I review documentation, I always do it in hardcopy. As
>a technical writer, I haven't ever found a reviewer who prefers to do it
>online. I don't know if my experience is representative. It is
>probably worth asking the group if they see themselves using the
>electronic mail tools you proposed.
I agree with you, I don't think it's possible to review a document longer
than 1 page from a terminal. The mechanism in the proposal is created
to manage comments and responses to them. It would be helpful to me
if you made comments electronically instead of in your hardcopy, but
even if you don't, that is how they will eventually be tracked.
>When I get copies for Symbolians to review, I'll ftp the files to a
>local machine and then print them. I don't completely understand the
>process for doing that. Do I really have to use a mail monitor program
I don't currently plan to copy my files every day to the FTP machine
(which is not the same as my development machine for security reasons),
only once per month. If you want a more current copy to review, you need
to tell me somehow to copy the file to the FTP machine so you can copy
it.
>to copy files? Also, I would want to copy dvi files, not tex files.
>How would I do that?
I can provide .dvi files, no problem.
>Is there anything ready for review now?
So glad to see you're anxious to review!
You will be receiving another mail message today that addresses when the
review should begin.
kc
∂26-May-88 2052 CL-Editorial-mailer editorial committee meeting
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 26 May 88 20:52:10 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA24618; Thu, 26 May 88 20:52:22 PDT
Date: Thu, 26 May 88 20:52:22 PDT
Message-Id: <8805270352.AA24618@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, CHAPMAN@decwrl.dec.com
Subject: editorial committee meeting
May 26, 1988
Meeting reminder and status of the standard
There will be a meeting of the editorial subcommittee on June
14, 1988, at 1:00 in the St. Croix Conference room at Symbolics.
Please let me know if you have a problem with the meeting time or
place.
I will be mailing the standard in its current state at the
end of next week.
Since the last meeting, I have been collecting information on
how a review of a document like the standard should be conducted.
One outcome of that exercise is the review proposal you should
have received that outlines a method for managing the review of
the standard and the resulting comments. It also became clear
that limiting the number of times a reviewer had to look at the
same document part was important to a thorough review of the
document. Therefore I suggest that you consider reviewing the
document after the completion of each phase of its life, i.e.
after it is a standardized version of the CLtL, after it has had
all the issues, CLOS, and the condition system incorporated (and
whatever else is going to be part of the standard), and after it
has had all your comments included.
For this meeting, I would like to accomplish the following:
1. I would like to get your concurrence that the review cycle
proposal is adequate, and that I may proceed with its
implementation.
2. Very shortly after this meeting I would like to start making
the phase I version of the standard (the standardized CLtL)
available for your review. For this to be possible, I need to
make sure that you think that at least some parts of the
document are ready for review.
3. A professional indexer can be available to index the standard
if we contract for her services in the near future. I'd like
to close the loop on this issue.
4. Check on the progress of the conformance proposal.
5. Check on the progress of the evaluation model.
6. Report on meetings with professional typesetters and book
designers, as well as the ANSI Editorial tutorial.
Looking forward to seeing you.
kathy chapman
∂10-Jun-88 0909 CL-Editorial-mailer standard mailing
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 10 Jun 88 09:09:32 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA00586; Fri, 10 Jun 88 09:08:30 PDT
Message-Id: <8806101608.AA00586@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 10 Jun 88 12:02
To: cl-editorial@sail.stanford.edu, PASQUALE%aitg.DEC@decwrl.dec.com,
CHAPMAN%aitg.DEC@decwrl.dec.com
Subject: standard mailing
Due to an unavoidable delay, the snapshot of the standard was not mailed
earlier this week as planned. Therefore, the following has been done:
1. There will be extra copies available at the editorial committee
meeting so that we can all look at it as we talk.
2. You should have a copy waiting for you when you get back home,
so there should be no need or you to waste space in your suitcase
(unless you need some light reading on the plane).
3. Borrow a copy from a local edit comm member? What about that,
Kent and Sonya?
Sorry for the inconvenience,
kc
∂16-Jun-88 1621 CL-Editorial-mailer Comments on the snapshot version
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 16 Jun 88 16:20:50 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa00793; 16 Jun 88 15:50 EDT
Received: from utokyo-relay by RELAY.CS.NET id ay01482; 16 Jun 88 15:41 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA25593; Thu, 16 Jun 88 22:04:02 JST
Received: by aoyama.cc.aoyama.junet (3.2/6.3Junet-1.0)
id AA02131; Thu, 16 Jun 88 14:53:45 JST
Date: Thu, 16 Jun 88 14:53:45 JST
From: Masayuki Ida <ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET>
Return-Path: <ida@aoyama.cc.aoyama.junet>
Message-Id: <8806160553.AA02131@aoyama.cc.aoyama.junet>
To: cl-editorial@SAIL.STANFORD.EDU
Subject: Comments on the snapshot version
Cc: ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET
Commonts on Fonts/Characters of the draft:
1) backquote character:
I have lots of experiences of trouble caused by the font of backquote sign.
Since in japan, we have not so long history to handle backquote character
in computer languages, Users/Novices often forget to take care of
the difference of quote sign; "'" and "`".
(Especially with bad fonts. )
(So, it may be a japan domestic problem,... but) I think
the choice of the font for quote character is important.
The current choice is quite normal but if possible,
more distinctive fonts will help us.
2) With some relations to backquote issue, definition/explanation
of the character set used in the document:
Since I was an official member of JIS Basic committee and
I joined the working team for check ANSI Fortan77 in japan,
I wonder why there is no section describing the character set
used in the draft, say in chapter 1.
I feel a kind of following table might be inserted.
The Character Set used in this Standard
symbol meaning
( open parenthesis or left parenthesis
) close parenthesis or right parenthesis
+ plus
...
' quote or single quote
` backquote
...
Masayuki Ida
∂05-Jul-88 1129 CL-Editorial-mailer Editorial Committee Meetings - June
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 5 Jul 88 11:29:34 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA04673; Tue, 5 Jul 88 11:29:06 PDT
Message-Id: <8807051829.AA04673@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 5 Jul 88 14:27
To: cl-editorial@sail.stanford.edu
Subject: Editorial Committee Meetings - June
Editorial Committee Meetings
June 14, 1987 and June 16, 1987, Boston
Attendees (at one or both meetings): Mary Boelke, Skona
Brittain, Kathy Chapman, Linda deMicheal, Dick Gabriel, Sonya
Keene, Barry Margolin, Bob Mathis, Jeff Piazza, Kent Pitman,
Jonathan Rees, Jeff Rosenking, Guy Steele, Walter van Roggen
1 SUMMARY OF ACTION ITEMS
It was agreed that phase 1 of the standard would be ready for
review by mid-July. This version may not contain all the changes
recommended at the editorial committee meeting and listed below.
However, those changes will be incorporated before the completion
of phase 2 if they are not in phase 1.
It was also agreed that the committee would try to have a
completed phase 1 document by the fall meeting. This means that
changes by the section writers will have to be to the editor no
later than October 1, preferably sooner. All the committee
members in the following list are section writers. See the
responsibilities of a section writer in the next section.
Person Responsibilities
Mary Boelke Packages, Symbols
Skona Brittain Control Structure, Sequences
Kathy Chapman Editor (see list of responsibilities below)
Chapters 1, 3, 5, 7, 8, Glossary
Make up glossary of error terms, get approved by
error, edit, and CLOS committees
Create a proposal for handling language subsets
Sonya Keene Characters, Strings
Gregor Kiczales CLOS
Barry Margolin Arrays, Evaluator, IO, Structures
Bob Mathis Numbers
Larry Masinter Files, Hashtables, Lists, Predicates
Jeff Piazza Declarations
Kent Pitman Chapter 2, Errors, Miscellaneous, Types
Jonathan Rees Chapter 4
Jeff Rosenking Macros, Streams
!
Page 2
Walter van Roggen Program Structure
2 SUMMARY OF MEETINGS
2.1 Meeting 1
A new outline was proposed and accepted:
Chapter 1 - Introduction
Chapter 2 - Objects and Types (the current section 3.1)
Chapter 3 - Object Syntax (the current section 3.2)
Chapter 4 - Evaluation and Compilation (the current sections
2.1, 2.2, and 2.4)
Chapter 5 - Other Topics (the current sections 2.3 and 3.3)
Chapter 6 - Catalog (the current chapter 4)
Chapter 7 - Language syntax summary (the current chapter 5)
Chapter 8 - Language formal semantics (the current chapter 6)
Glossary
A method of delegating responsibility was proposed and accepted.
A summary of the method follows.
The chapters have been EDITED. That means that information
from CLtL has been included. The job of the section writer is to
take over the responsibility for the assigned sections. If there
is a question about a section the writer is responsible for, the
question goes to the writer. After the section has been turned
over to the writer, both the writer and the editor will be making
changes, so the changes have to be coordinated and well marked. A
summary of section writer and editor responsibilities follows.
Responsibilities of the section writer.
1. Get the most recent copies of the assigned material.
2. Find problems, make corrections, mark corrections in original.
Send corrections electronically, or mail them hardcopy to the
editor.
3. Refrain from making any changes while the document is in the
editor's control unless they are specifically requested.
!
Page 3
4. Answer questions about the sections.
5. Notify the committee as soon as you learn that you will not
have the time to help on the editorial committee.
6. Respond to comments, incorporate the comment, or let the
commenter know why it wasn't incorporated. Review response
with editor before responding.
7. Forward comments and your response to the editor so they can
be tracked.
8. Receive comments on your section from the editor and draft
responses.
9. Use the cl-editorial mailing list and other experts in your
area to resolve technical issues.
10. Be prepared to review the entire document after the completion
of each phase.
Responsibilities of the editor:
1. Make sections available to the writers upon request.
2. Refrain from making changes while the document is in the
writer's control.
3. Include X3 issues, CLOS, ...
4. Annotate editorial changes in the source file.
5. Incorporate changes made by the writers into the proper
sections and proliferate those changes through the document if
necessary.
6. Track comments on all sections.
7. Forward comments to the appropriate section writer.
8. Assist in resolving technical issues.
9. Resolve issues of style and format.
Copies of the snapshot of the standard were distributed and
reviewed by small groups. Kathy Chapman will incorporate the
recommendations suggested by the groups except where otherwise
noted.
1. Group 1: current Chapter 2: Jonathan Rees, Dick Gabriel,
Jeff Piazza
!
Page 4
Recommendations:
1. There should be more subsections in this chapter.
2. There should be more detail in the evaluation model.
(Jonathan Rees will guide this effort.)
3. There should be a liaison person who tracks the compiler
committee issues and insures their correct insertion into
this chapter in the standard. (Kathy Chapman is working
with Sandra Loosemore to make sure this happens.)
2. Group 2: current Chapter 3: Barry Margolin, Sonya Keene,
Walter van Roggen, Linda deMicheal
Recommendations:
1. A list of all `tools' that apply to a certain object is to
be supplied after the object description.
2. There should be more sections and subsections, also more
introductory material before each section break. In
particular, there should be a separate section for each
data type. Possible headings would be `Type Hierarchy',
`Type Declarations', data type headings, `Coercion', `Type
Specifiers'.
3. Move paragraphs at the bottom of page 3-3 and the top of
page 3-4 elsewhere?
4. Move the discussion on arguments somewhere else?
5. Clarify the use of the terms type and data type, and be
consistent in their usage.
6. Define the distinction between an object and a true
object.
7. Move Figure 3-4 to earlier in the section.
8. Move print-read consistency rules.
9. Need to distinguish between an object and the printed
representation of an object. (e.g. p. 3-31)
10. Move character ordering information to section where
characters as a data type is described.
11. Move figure 3-9 to earlier in the chapter.
12. Pages 3-35 through 3-39 contain material that needs
clarification or belongs elsewhere.
!
Page 5
13. Correct all numbering schemes for readability.
14. Give an overview of types before giving details.
15. Change the chapter names from `Object Syntax' to
`Read/write Syntax' and `Objects and Types' to `Data
Types'. (This is still under consideration.)
3. Group 3: current Chapters 1 and 4: Jeff Rosenking, Mary
Boelke, Kent Pitman, Skona Brittain
Recommendations:
1. Separate `Definitions' into `Notational Conventions' and
glossary.
2. There is an issue about when function definitions should
be grouped. Will the presence of a good index solve the
problem of finding a function the isn't alphabetically
organized? Listing all functions in the format we are now
using would mean a great many blank pages.
3. Rename `Purpose' to `Description'. This heading will
contain a summary of the tool in the first one or two
sentences. It will also contain all intended aspects of
the tool, but does not necessarily have to include all
fields referenced below it.
4. Leave all fields in; decide on deletion of blank ones
before final review. For example, under Side Effects, the
word `none' should be entered if there are no entries,
whereas, if there are no entries under See Also, that
heading should be deleted.
5. In syntax field and in running text, leave out colons on
keywords.
6. Rename `Errors Signaled' to `Conditions'. This field will
contain all errors.
7. Rephrase the definitions of the fields at the beginning of
Chapter 4.
8. Add `Affected By:' heading. (This is under
consideration.)
2.2 Meeting 2
At this meeting, responsibilities for the various parts of
the standard were designated as follows:
!
Page 6
Chapter 1 - Kathy Chapman
Chapter 2 - Kent Pitman
Chapter 3 - Kathy Chapman
Chapter 4 - Jonathan Rees
Chapter 5 - Kathy Chapman
Chapter 6 - see below
Arrays - Barry Margolin
Characters - Sonya Keene
Control Structure - Skona Brittain
Declarations - Jeff Piazza
Errors - Kent Pitman
Evaluator - Barry Margolin
Files - Larry Masinter
Hashtables - Larry Masinter
IO - Barry Margolin
Lists - Larry Masinter
Macros - Jeff Rosenking
Miscellaneous - Kent Pitman
Numbers - Bob Mathis
Packages - Mary Boelke
Predicates - Larry Masinter
Program Structure - Walter van Roggen
Sequences - Skona Brittain
Streams - Jeff Rosenking
Strings - Sonya Keene
CLOS - Gregor Kiczales
Structures - Barry Margolin
!
Page 7
Symbols - Mary Boelke
Types - Kent Pitman
Chapter 7 - Kathy Chapman
Chapter 8 - Kathy Chapman